TLDR: Messing with expanding release changelog to:

• increase coverage of fixes/changes/additions
• make/keep easy to read

TODO:

• First pass that itemizes all non-translation related commits
• Categorize items
• Lightly edit items for readability
• Heavily edit for casual reading

Editing a changelog to make it presentable, readable, and useful (beyond just skimming commit messages) takes time. This is an experiment to see what's involved, see if it's worthwhile, get some feedback from the community, start somewhere and improve as we go along, etc.

The existing changelog often leaves users with an inappropriate impression of what has changed. Incomplete ones (or ones that aren't easy to comprehend in a relatively quick manner to non-developers) impact trust and confidence.

It's about not only what's been added, but fixed/updated/etc. And bugs and regressions will happen, but they're easier to accept if changes are not coming out of a "black box" (I'm talking from the perspective of those that aren't actively involved in the development - or which are only involved in development on the peripheral or elsewhere within @nextcloud).

I further propose that if we decide to keep doing something similar to this, that we:

• add a checkbox to the default PR template (after the "Tests written") that says something like:
  • Entry added to CHANGELOG.md for this change
    • in the Unreleased section
    • A preliminary one-liner is fine the changelog editor may tweak it at release time as deemed appropriate
  • This will make life way easy for compiling these and disperse the extra work so that it can become more sustainable (that's my hypothesis anyhow)
• split up release duties to keep things more manageable (loosely; sometimes this will still be the same person):
  • changelog editor
  • builder/deployer/uploader
• have the changelog be 99% done with the first beta/RC
• take the time to continuously improve the "possible to automate better" areas of the release process
• push out these stronger changelogs with betas/RCs to foster/encourage user/community testing (builds excitement and also makes it clearer what areas are the ones likely to need testing)

I'll also include this quote from Keep a Changelog because it seems relevant: 😄

A changelog which only mentions some of the changes can be as dangerous as not having a changelog. While many of the changes may not be relevant - for instance, removing a single whitespace may not need to be recorded in all instances - any important changes should be mentioned in the changelog. By inconsistently applying changes, your users may mistakenly think that the changelog is the single source of truth. It ought to be. With great power comes great responsibility - having a good changelog means having a consistently updated changelog.

• Tests written, or not not needed